i urn min in nil inn mi ihii hi u iim mi urn in in mi 

US006563793B1 

(12) United States Patent ao) Patent No.: us 6,563,793 bi 

Golden et al. (45) Date of Patent: May 13, 2003 



(54) METHOD AND APPARATUS FOR 

PROVIDING GUARANTEED QUALITY/ 
CLASS OF SERVICE WITHIN AND ACROSS 
NETWORKS USING EXISTING 
RESERVATION PROTOCOLS AND FRAME 
FORMATS 

(75) Inventors: Michael E. Golden, Pleasanton, CA 

(US); William A. Rundquist, Fremont, 
CA (US) 

(73) Assignee: Enron Warpspeed Services, Inc., 
Pleasanton, CA (US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/200,161 

(22) Filed: Nov. 25, 1998 

(51) Int. CI. 7 H04L 12/28; H04L 12/66 

(52) U.S. CI 370/236; 370/355; 370/395.2; 

370/401; 370/428; 370/477; 709/227; 709/238 

(58) Field of Search 370/230, 231, 

370/235, 352, 355, 389, 396, 400, 401, 
410, 428, 465, 466, 468, 477, 395.1, 395.2, 
395.21, 236; 709/201, 203, 227, 228, 229, 
230, 238, 242, 249 

(56) References Cited 

U.S. PATENT DOCUMENTS 

5,732,078 A • 3/1998 Arango 370/355 

5/781,537 A * 7/1998 Ramaswami et al 370/254 

5,903,559 A * 5/1999 Acharya et al 370/355 

6,021,263 A * 2/2000 Kajoory et al 395/200.62 

6,028,862 A * 2/2000 Russel et al 370/397 

FOREIGN PATENT DOCUMENTS 



WO 

wo 



WO 98/37730 
WO 98/47309 



8/1998 
10/1998 



OTHER PUBLICATIONS 



Ghanwani, A. et al., A Framework for Providing Integrated 
Services Over Shared and Switched IEEE 802 LAN Tech- 
nologies, Internet Engineering Task Force, Internet Draft, 
pp. 1^3, (May. 1998). 

Yavatkar, R. et al., SBM (Subnet Bandwidth Manager): A 
Protocol for RSVP-based Admission Control Over IEEE 
802— style networks, Internet Engineering Task Force, Inter- 
net Draft, pp. 1-61, (Nov. 1998). 

Rosen, E. et al., Multiprotocol Label Switching Architecture , 
Network Working Group, Internet Draft, pp. 1-58, (Jul. 
1998). 

(List continued on next page.) 
Primary Examiner — Alpus H. Hsu 

(74) Attorney, Agent, or Firm — Gary L. Bush; Andrews & 
Kurth, LLP 



(57) 



ABSTRACT 



Seaman, M. et al., Integrated Service Mappings on IEEE 
802 Networks, Internet Draft, pp. 1-10, (Nov. 1997). 



A method and apparatus provide reserved bandwidth and 
QOS/COS virtual circuit connections in a network using 
both conventional and novel reservation protocols and frame 
formats. An apparatus according to the invention includes an 
enterprise control point that communicates with switches via 
a reserved signaling channel. The switches have been 
upgraded or replaced to include enhanced functionality. The 
enhanced switches detect packets that include requests for 
reserved connections according to existing reservation pro- 
tocols such as RSVP and IEEE 802.1P/Q. Such detected 
packets are forwarded to the enterprise control point for 
processing via a reserved signaling channel. The enterprise 
control point identifies a path within the network that can 
satisfy the requested QOS/COS and reserves the requested 
resources all along the path from beginning to end. A method 
according to the invention includes detecting packets that 
include requests for reserved connections according to exist- 
ing reservation protocols such as RSVP and IEEE 802.1P/Q, 
forwarding detected packets to an enterprise control point 
for processing via a reserved signaling channel, identifying 
a path within the network that can satisfy the requested 
QOS/COS and reserving the requested resources all along 
the path from beginning to end. 
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METHOD AND APPARATUS FOR 
PROVIDING GUARANTEED QUALITY/ 
CLASS OF SERVICE WITHIN AND ACROSS 

NETWORKS USING EXISTING 
RESERVATION PROTOCOLS AND FRAME 
FORMATS 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a method and apparatus 
for providing guaranteed quality and/or class of service 
(QOS/COS) in a local or wide area network or across 
networks, and more particularly, to a technique for adapting 
an existing packet-switched/routed infrastructure so that 
on-demand reserved-bandwidth virtual circuit connections 
with guaranteed QOS and/or COS between any endstations 
within the network or between networks can be established, 
while providing interoperation with and improving the per- 
formance of existing reservation protocols and frame for- 
mats. 

2. Description of the Related Art 

The Internet has traditionally provided support for "best 
effort" traffic only. That is, traffic will be propagated along 
a path from a source to a destination depending on the 
congestion or lack thereof existing at each "hop" (typically 
a router) along the way. If there is little congestion, the traffic 
will be propagated quickly. If the path is heavily congested, 
traffic will be buffered (usually first -in-first -out) at congested 
locations until propagation is possible, which may substan- 
tially delay the traffic. Moreover, there is no way for a sender 
to know ahead of time whether the desired transmission will 
succeed or fail. This is because Internet traffic follows a 
"thread-the-needle" approach, wherein each hop or router 
knows only about the next hop downstream. If traffic at the 
next hop is extremely congested, the router will nevertheless 
attempt to forward traffic thereto without searching for an 
alternate route around it. If the traffic can't be forwarded 
within a timeout period, the transmission will fail. 

The existing Internet "best effort" design is suitable for 
low priority traffic where transmission latency is acceptable, 
albeit annoying. However, with the proliferation of new 
technologies using real time applications such as video 
conferencing and Internet telephony, guaranteed quality of 
service (QOS) with minimal and predetermined transmis- 
sion latency has become increasingly desired. Such service 
is not possible with the traditional "best effort" design. 

Recently, protocol-based QOS solutions have been 
attempted. One such solution is Resource Reservation Pro- 
tocol (RSVP), which is an application layer protocol. This is 
illustrated in FIG. 1. Downstream messages along the path 
from a sender SI to remote receivers RCV1, RCV2 and 
RCV3 include Path, PathTear, ResvErr, and ResvConf. 
Upstream messages along the path from receivers RCV1, 
RCV2 and RCV3 to sender SI include Resv, ResvTear and 
PathErr. 

A sender SI desiring to establish a connection having a 
specified bandwidth or latency with remote receivers RCV1, 
RCV2, and RCV3 issues a Path message to the receivers. 
The Path message must be processed at each hop or router 
Rl, R2, R3, R4 in the path between the sender and the 
respective receiver. Each receiver RCV1, RCV2, RCV3 
determines the type or amount of service that will be 
required for the connection from the Adspec object of the 
Path message and responds with a Resv message of its own 
having parameters defining the required service. The Resv 
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message is threaded back upstream along the identical path 
by which the Path message was sent. Each router must 
determine whether it has the resources to satisfy the required 
reservation. If so, it reserves the connection in its path slate, 

5 and forwards the Resv message back upstream. If it doesn't 
have the required resources, it returns an error message back 
downstream toward the appropriate receivers. RSVP is 
described in R. Braden et al., "Resource ReSerVation Pro- 
tocol (RSVP) — Version 1 Functional Specification," RFC 

10 2205, September 1997. In order to work effectively, 
obviously, every router at each hop along the path between 
sender and receiver must support RSVP. 

RSVP is designed for reserving resources along paths 
stretching across multiple networks. Since it is an applica- 

15 tion layer protocol, it can not be understood or implemented 
in layer 2 devices such as switches within a local network 
that often separate a sender or receiver from their gateways 
to other networks. Accordingly, even if RSVP were fully 
supported between all networks, reserved connections estab- 

20 lished using it would still be prone to congestion problems 
within the local networks of the sender and receiver. 

Moreover, other protocols have been or are in the process 
of being developed to improve and provide differentiated 
classes of service (COS) between networks, and attempts 

25 have been made to integrate these proposals with RSVP. 
Multiprotocol Label Switching (MPLS) is a scheme in 
which labels are associated with streams of packets between 
communicating hosts. These labels are used by MPLS- 
capable routers in the path between the hosts to cause all 

30 packets in the stream to be forwarded the same way. This 
further allows hosts to use predetermined explicit routing. 
MPLS is described in R. Callon et al, "A Framework for 
Multiprotocol Label Switching," Network Working Group 
Internet-Draft, Nov. 21, 1997. When integrated with RSVP, 

35 the labels are carried in RSVP objects within Path and Resv 
messages. 

Differentiated Services (diff-serv) allows definition and 
selection of different discrete levels of service. Rather than 
assigning the required level of service on a per-flow basis as 
in RSVP, diff-serv assigns levels of service on a per-packet 
basis in accordance with the contents of a DS field in each 
packet's header. Accordingly, when used in conjunction with 
RSVP, means must be provided for marking the DS fields in 
45 transmitted packets appropriately for each flow. Diff-serv is 
described in Y. Bernet et al., "A Framework for Differenti- 
ated Services," Diff-serv Working Group Internet-Draft, 
May 1998. 

MPLS and diff-serv are two different competing 

50 approaches for providing COS using RSVP signaling. 
However, the two approaches are incompatible. 
Accordingly, frames of packets sent using one format will 
not be accorded the desired level of service over devices 
only supporting the other format. 

55 Moreover, there is no way that MPLS and diff-serv can 
know, ahead of time, whether or not the requested COS 
signaled in the frames can be effected through all forwarding 
devices from source to destination. This is because they 
suffer from relying on RSVP as the signaling protocol since 

60 its thread-the-needle approach can't see the whole network. 
This weakness centers around comingled best effort traffic. 
Without strict control mechanisms which can limit the 
impact on a piece of network equipment, it is not possible to 
implement true QOS/COS since the best effort traffic, even 

65 though it may be in different queues or on different physical 
interfaces, can still consume routine resources within the 
router which in turn can add unpredicted latency to the 
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QOS/COS traffic, thus having a negative impact on the connections completely end-to-end. Integration of IEEE 

delivery and therefore the quality and/or level of the service. 802.1-style LANs with Internet level reservation protocols 

The basic issue is that RSVP-controlled devices are such as RS VP is discussed in an IETF Draft by A. Ghanwani 

generally packet switches. Every packet switch introduces el aL e ° titled Framework for Providing Integrated Ser- 

jitter. In an RSVP-controlled device (which can be a 5 vices Over Shared and Switched IEEE 802 LAN 

J u . 4 .„ . „v , t . . . Technologies, March 1998. This proposed framework 

switch or a routed ), packets arriving on a port are . . , & n * . , t , x . . t \ r . _ 

, . , . . ™ includes a Bandwidth Manager that acts as a proxy between 

commingled; each packet may belong to any priority. Ttae , EE£ gQ2 lp/Q tfaffic QQ £ LAN/MAN an ^ RS V P lraffic 

are two basic designs for controlled-QOS switching sys- on me WAN Qr , mernel A ^ Bandwidlh Ma 

terns: input-queuing and output-queuing. If the switch is coasistem with the proposed framework is described in an 

"mput-queueing", each packet is classified onto one of 10 mTF Draft by R Y avatkar et aL entitled "SBM (Subnet 

several input queues on the arriving port of the switch. There Bandwidth Manager): A Protocol for RS VP-based Admis- 

needs to be one queue per level of service supported, or s j on Control over IEEE 802-style networks " March 1998. 

various levels of service will be commingled in that queue. fj G 2 illustrates a centralized implementation of the 

Depending on the switch design, each packet may be "tar- bandwidth manager described by Ghanwani. In this 

geted" to an output port upon queueing, or that may be done 15 implementation, the bandwidth manager 10 includes a band- 

at a later stage. width allocator module that is responsible for admission 

In an input-queued design, the output port polls each control for an entire subnet (i.e., a layer 2 domain in which 

queue that might have traffic for that output port when the traffic between hosts therein does not require a layer 3 

port becomes available. With QOS handling, it handles forwarding function). Since bandwidth manager 10 is colo- 

higher priority queues before lower priority queues. Now, 20 catcd with a layer 2 device, signaling between it and host 12 

presume the output port is reading out a long, low priority and router 14 » Permed at the data link layer (layer 2). 

packet. A high priority packet arrives, and is queued. The M shown > host 12 13 separated from router 14 by one or 

high priority packet can not be transmitted until the lower more ^ 802.1P/Q switches or bridges 16. When a sender 

priority packet is completely sent. This causes the high m another . netw ° rk to ™™ a ^f 1 ™ ™ th ^ 12 

, t t ^« :UtA 5,. : a fo w i n „„ ttr t„ ™t ♦K^.Sh 25 as a receiver, the Path message from the sender reaches 

pnonty packet to itter, i.e it takes longer to geuhrough from ^ for Rsyp 

d» router than one that amved without a low-pnonty packet ^ r J ter 14 stor module that 

being transmitted. In fact, it can cause "convoying" , the ^ applic ^ tioo layer of t £ e nos , 12 t0 its layer 2 

behavior of several high pnonty packets backing up while address ^ formats 

an extended Path message to be sent to 

waiting for the low-pnonty traffic to clear. ^ ho&{ u yia bandwidth managcr 10 . Bandwidth manager 10 

Output^queued packet switches have similar problems. receives this extended Path message and the bandwidth 

Such problems are caused by the fundamental notion of allocator module builds its own path state for the connection 

packet switching: all packets must be transmitted whole. All and forwards the message to host 12, thus inserting itself as 

packet switches cause some amount of jitter in the trans- me "hop" on the path. 

mission path; that's why there's a maximum packet size. 35 WheQ host n returns a Resv message to bandwidth 

Control of end-to^end jitter was the biggest reason for ma nager 10, the bandwidth allocator determines whether to 

choosing the outrageously small maximum packet size (so admit the connection trJ r 0Ugh the subnet. This involves 

small, they called it a "cell") for ATM. determining whether enough resources are available to 

One approach to solve the issue of latency is to use a TDM handle the required level of service. If not, an error message 

switch. In a TDM switch, all bytes are transmitted ^ j s returned to the receiver. If sufficient resources are 

synchronously, and no queueing is necessary for completion available, the Resv message is forwarded upstream to router 

of the packet. Therefore, a TDM switch provides constant 14 and from thence to the sender. The bandwidth allocator 

latency, for all traffic. Using a TDM switch, however, maps tne required quality of service into a particular traffic 

sacrifices the ability to multiplex variable speed traffic. tna t has a corresponding priority that is designed to 

RSVP is mainly intended for communications between 45 accomplish the desired service. Based on this mapping, the 

hosts in different networks. Meanwhile, within networks, bandwidth manager tells host 12 and router 14 the user_ 

data link layer QOS/COS solutions have been proposed. In priority with which to specify in the layer 2 frames in order 

particular, for IEEE 802 class LANs (the most common), the to accomplish the required level of service. Traffic belonging 

revised IEEE 802.1D data link layer frame format defines to the session within the network is thus formatted into layer 

static priority queueing for switches that implement multiple 50 2 frames that are forwarded between host 12 and router 14 

queues. IEEE 802. ID is described in "MAC Bridges," by switches 16, with a priority that is aimed at effecting the 

ISO/IEC 10038, ANSI/IEEE Std 802.1D (1993). More required quality of service. 

recently, IEEE 802.1P/Q proposes differential traffic class Problems remain. SBM sees only resources within its 

queueing and access to media based on a "user_priority" subnet — it has no overview of path from beginning to end 

signaled in frames. This is described in "IEEE Standards for 55 across different networks. SBM is unable to deal with 

Local and Metropolitan Area Networks: Virtual Bridged resources individually, and unable to manage resources as a 

Local Area Networks," Draft Standard P802.1Q/D9, Feb. whole. SBM further requires that extensions be made to 

20, 1998. Layer 2 devices supporting such frame formats RSVP in order for its services to be supported — if these 

queue traffic for forwarding between ports with different extensions are not used, SBM can not assist the connection, 

levels of priority, thereby permitting high priority traffic to 60 Moreover, this approach for supplying QOS within networks 

propagate with minimal latency, while preserving "best requires using IEEE 802.1P/Q, which further requires 

effort" transmission of lower priority traffic. extended frame format not compatible with previous frame 

Realizing that the LAN is often the first and last "hop" formats. Thus it requires switches that support IEEE 

between a sender and receiver, RSVP proponents have 802.1P/Q and/or multiple queues. Likewise, SBM requires 

attempted to marry the reservation functions of the applica- 65 endstations that support IEEE 802.1P/Q. Further, switches 

lion layer with the priority queueing of the IEEE 802.1P/Q within a network will suffer the commingling best effort 

data link layer for the purpose of establishing reserved traffic problems described above with respect to RSVP. 
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Co-pending U.S. patent application Ser. No. 09/060,520, 
filed Apr. 14, 1998 entitled "Method and Apparatus for 
Providing Guaranteed Quality of Service in a Local or Wide 
Area Network," commonly owned by the assignee of the 
present invention, the contents of which are incorporated 5 
herein by reference, solved the problem of providing guar- 
anteed quality of service in a network without fundamentally 
altering the network infrastructure or requiring frame format 
or other protocol extensions. Although the co-pending appli- 
cation dramatically advances the state of the art, there is still 10 
a need to provide interoperation between the concepts and 
advantages of the co-pending application and existing and 
emerging intra- and internetwork reservation protocols and 
frame formats. The present invention fulfills this need, 
among others. 15 

SUMMARY OF THE INVENTION 

Accordingly, an object of the present invention is to 
provide reserved bandwidth and QOS/COS virtual circuit 
reserved connections in a local area network using both 
conventional and novel reservation protocols and frame 
formats. 

Accordingly, an object of the present invention is to 
provide reserved bandwidth and QOS/COS virtual circuit 
reserved connections between local area networks using 
both conventional and novel reservation protocols and frame 
formats. 

Another object of the invention is to provide QOS/COS 
virtual circuit reserved connections within a network using 
existing reservation protocols and frame formats that does 
not require extensions or revisions to such existing protocols 
and frame formats. 

Another object of the invention is to provide QOS/COS 
virtual circuit reserved connections within a network that 
does not disrupt the overall network infrastructure. 

The present invention achieves these objects and others. 
According to one aspect of the invention, an apparatus 
includes an enterprise control point that communicates with 
switches within a network via a reserved signaling channel. 
The switches have been upgraded or replaced to include 
enhanced functionality. The enhanced switches detect pack- 
ets that include requests for reserved connections according 
to existing reservation protocols such as RSVP and IEEE 
802.1P/Q. Such detected packets are forwarded to the enter- 
prise control point for processing via a reserved signaling 
channel. The enterprise control point identifies a path within 
the network that can satisfy the requested QOS/COS and 
reserves the requested resources all along the path from 
beginning to end. 

According to another aspect of the invention, a method 
according to the invention includes detecting packets that 
include requests for reserved connections according to exist- 
ing reservation protocols such as RSVP and IEEE 802.1P/Q, 
forwarding detected packets to an enterprise control point 
for processing via a reserved signaling channel, identifying 
a path within the network that can satisfy the requested 
QOS/COS and reserving the requested resources all along 
the path from beginning to end. 

According to a further aspect of the invention, an appa- 
ratus according to the invention further includes a network 
control system server coupled to different local area net- 
works and also coupled to controllable network elements 
within an interconnection path between the local area net- 
works. Enterprise control points within the network are 
further adapted to communicate with the network control 
system server. The network control system server is adapted 



to identify an interconnection path between the local area 
networks that can satisfy the requested QOS/COS, the path 
including one or more controllable network elements, and to 
switch up the connection between the local area networks. 

According to a further aspect of the invention, a method 
according to the invention further includes forwarding 
detected requests for reserved connections to a network 
control system server coupled to different local area net- 
works and also coupled to controllable network elements 
within an interconnection path between the local area 
networks, identifying an interconnection path between the 
local area networks that can satisfy the requested QOS/COS, 
the path including one or more controllable network 
elements, and switching up the connection between the local 
area networks via the identified interconnection path. 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other objects and advantages of the present 
invention will become apparent to those skilled in the art 
20 after considering the following detailed specification, 
together with the accompanying drawings wherein: 

FIG. 1 illustrates an example of using RSVP in a con- 
ventional multicast session; 
25 FIG. 2 illustrates a conventional framework for providing 
integrated services in a LAN; 

FIG. 3 is a top-level block diagram illustrating an example 
of the invention adapted for use with LANs interconnected 
via the public Internet and/or private network /virtual private 
3Q networks; 

FIG. 4 illustrates a network that provides interoperation 
with internetwork reservation protocols such as RSVP 
according to the example of the invention in FIG. 3; 
FIG. 5 is a block diagram further illustrating the func- 
35 tionality an ECP adapted for use in a network such as that 
illustrated in FIG. 4; 

FIG. 6 is a block diagram further illustrating the upgraded 
functionality of a switch adapted for use in a network such 
as that illustrated in FIG. 4; 
40 FIG. 7 illustrates another example of a network that 
provides interoperation with internetwork reservation pro- 
tocols such as RSVP and that includes both conventional and 
novel switch services in accordance with the example of the 
invention in FIG. 3; 
45 FIG. 8 illustrates another example of a network that 
provides guaranteed COS while providing interoperation 
with IEEE 802.1P/Q frame formats in accordance with the 
example of the invention in FIG. 3; 
50 FIG. 9 illustrates another example of a network that 
provides guaranteed COS while providing interoperation 
with IEEE 802.1P/Q frame formats in accordance with the 
example of the invention in FIG. 3; 

FIG. 10 is a block diagram further illustrating the func- 
55 tionality of a host adapted for use in a network such as that 
illustrated in FIG. 9; 

FIG. 11 is a top-level block diagram illustrating an 
example of the invention adapted for use with LANs inter- 
connected via a private network/virtual private network and 
60 further including a network control system server for con- 
trolling internetwork connections; 

FIG. 12 is a block diagram further illustrating the func- 
tionality of an ECP adapted for use in a local area network 
including in the network illustrated in FIG. 11; 
65 FIG. 13 is a block diagram further illustrating the func- 
tionality of a network control system server adapted for use 
in the network illustrated in FIG. 11; 
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FIG. 14 is a block diagram further illustrating the func- 
tionality of a switch commander adapted for use in the 
network illustrated in FIG. U; 

FIG. 15 is a block diagram illustrating another example of 
internetwork connections in a network such as that illus- 5 
trated in FIG. 11; 

FIG. 16 is a top-level block diagram illustrating an 
example of the invention adapted for use with LANs inter- 
connected via a broadband network such as that described in 
co-pending application Ser. No. 08/966,634 and further 10 
including a network control system server for controlling 
internetwork connections; 

FIG. 17 is a block diagram further illustrating the func- 
tionality of a premises switch adapted for use in a local area 
network in the network illustrated in FIG. 16; and 15 

FIG. 18 illustrates another example of a local area net- 
work adapted for use with the broadband network in accor- 
dance with the invention illustrated in FIG. 16. 

DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 20 

The invention will now be described with reference to an 
exemplary implementation depicted in FIG. 3. In this 
implementation, LANs A and B are local area networks 
having enhanced QOS/COS functionality according to the 2 s 
invention, while LAN C is a conventional local area net- 
work. Senders and receivers in LANs A, B and C commu- 
nicate using conventional reservation protocols via the pub- 
lic Internet 24 and/or via a private network or virtual private 
network 26 (e.g. leased lines, X.25, Frame Relay, ISDN, or 30 
ATM). In a manner that will be described in more detail 
below, such communications will be detected and managed 
within LANs A and B so as to guarantee the desired 
QOS/COS within LANs A and B. However, in this example 
of the invention, the QOS/COS of such communications 35 
traversing between LANs A and B and within LAN C will 
still be prone to lack of support for reservation protocols 
within the public Internet 24 or private network 26 and/or 
overall internetwork congestion. 

FIG. 4 illustrates portions of a local area network 20 such 40 
as LAN A or B in FIG. 3 configured in accordance with the 
principles of the invention. This embodiment is designed to 
provide local network interoperation with application layer 
reservation protocols such as RSVP. As shown, it includes 
enterprise control point (ECP) 50, host 52, router 54 and 45 
intermediate switches 56. 

Host 52 and router 54 in the embodiment of the invention 
shown in FIG. 4 can be any host or router that has the 
capability of signaling using application layer reservation 
protocols such as RSVP, unlike the conventional framework 50 
in FIG. 2 that requires the host and router to include a 
requestor module for communicating with the bandwidth 
manager. For example, host 52 is a conventional workstation 
such as a PC having an Ethernet network interface card 
(NIC) such as a Fast EtherLink XL from 3 Com Corp. of 55 
Santa Clara, Calif., and running a networking operating 
system such as Windows NT from Microsoft Corp. of 
Redmond, Wash., including NIC RSVP client drivers for 
signaling with RSVP. Router 54 is, for example, a Cisco 
7000 multiprotocol router by Cisco Corp. of San Jose, Calif. 60 
Intermediate switches 56 are, for example, flash memory 
upgradable switches such as Layer 2 Etherswitch 1100 
switches from 3Com Corp. of Santa Clara, Calif. ECP 50 is 
either a standalone processor and software that communi- 
cates with a switch in network 20 as any other endstation, or 65 
it may be incorporated within the existing functionality of an 
existing switch via a firmware upgrade, for example. 
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Although the principles of the invention can be applied to 
internetwork signaling protocols other than RSVP, for clar- 
ity only RSVP will be described in detail. Moreover, 
although only one host 52 and router 54 is shown, it should 
be apparent that a network can have many hosts and routers 
thai support reservation protocols. It should be likewise 
apparent that the number of intermediate switches between 
host 52 and router 54 can be just one, or more than two, 
although two switches 56 are shown in FIG. 4. 

As shown in FIG. 4, ECP 50 includes a path/device 
discovery function 60, a connection monitor function 62, a 
connection controller function 64, and a signaling interface 
function 66. Intermediate switches 56 each include a reser- 
vation interface function 68 and enhanced switch engine 
function 70. 

As the functionality of ECP 50 is shown in more detail in 
FIG. 5, signaling interface function 66 provides the ability to 
communicate with switches 56 via a reserved signaling 
channel 58 (described in the co-pending application Ser. No. 
09/060,520). Path/device discovery function 60 learns what 
network elements and paths between endstations exist 
within the LAN and maintains respective lists of each in 
network elements registry 57 and path list 59. The network 
elements include endstations such as host 52 and router 54 
and switches such as switches 56, as well as the interfaces 
between them (e.g. switch ports). Information maintained in 
network elements registry 57 by path/device discovery func- 
tion 60 for each network element preferably includes their 
respective MAC addresses and bandwidth capacity. Con- 
nection controller function 64 is responsible for setting up 
and tearing down reserved connections within network 20 in 
response to sessions using existing and emerging protocols 
such as RSVP in a manner that will be described in more 
detail below. Connection monitor function 62 maintains a 
permanent list of connections, including respective perma- 
nent connection records 65 that show the elapsed time of the 
connection, the parties involved, and the resources used. 
Such records can be used for billing and resource 
management, for example. 

The functionality of intermediate switches 56 is shown in 
more detail in FIG. 6. Such switches include switch engine 
functions for layer 2 forwarding of packets according to 
conventional techniques. Similarly as described in the 
co-pending application Ser. No. 09A)60,520, however, such 
switches have been upgraded or replaced so as to include the 
functionality of the invention. Accordingly, switches 56 
include an enhanced switch engine 70 that makes forward- 
ing decisions based on a conventional switch table 69 as well 
as a novel reserved connection pairs list 67. Enhanced 
switch engine 70 further includes functionality for detecting 
packets using reservation protocols such as RSVP and 
forwarding information concerning them to ECP 50 via 
reservation interface 68. Moreover, switches 56 include 
additional functionality in the form of reservation interface 
function 68 that communicates with ECP 50 via reserved 
signaling channel 58 to exchange information about 
reserved connections. The effect of the above-noted 
enhanced functionality is that switches 56 give higher pri- 
ority to packets belonging to reserved virtual circuit con- 
nections than to other packets contending for access to the 
same ports as needed by the reserved virtual circuit 
connections, thereby guaranteeing the desired service for the 
reserved connections. 

It should be apparent to those skilled in the art that 
switches 56 are not necessarily layer 2 forwarding devices; 
rather, the enhanced functionality present within switches 56 
could be applied to application layer forwarding devices and 
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routers in addition to layer 2 forwarding devices. Hence, the the path, and thus the overall capacity of the path, in 

principles of the invention are applicable to environments accordance with bandwidth consumed by currently existing 

having a plurality of subnets, or packet-switched WANs connections listed in its current connection list 63. The 

(possibly including some or all of private network/virtual remaining bandwidth available through each link, switch, 

private network 26), including a plurality of layer 2 and 5 and swilch P ort ma Y be further reduced by rules and policies 

layer 3 switches and/or routers. However, for simplicity, this established for the network, such as allowing certain hosts to 

example of the invention describes only switches 56 within b ave P™ 1 ^ *™ nscntd bandwidth connections over other 

, ^h™,!, in hosts, and the like, such rules and policies being stored in its 

a common network 20. * ' . . . . r , , , & . . 

...... , policies list 61. It should be noted that, alternatively or 

As a further alternative, it should be noted that packets additionally, ECP 50 could communicate with a policy 

using reservation protocols may be intercepted at the host's W scrver me QCtwork for determination on 

NIC rather than at switches 56. However, this would require whether to admit the connection. 

that the NIC be upgraded with such functionality and with If thc overall capac i ty 0 f the first available path between 
an interface to ECP 50. host 52 an d r0 uter 54 is not sufficient for the bandwidth 
The details of the operation of a local area network 20 required by the requested connection, the next path in the list 
illustrated in FIG. 4 having the additional functionality of 15 is checked (if more than one path exists), and on to the end 
the present invention will now be described. More of the list. It should be noted that some paths in the list may 
specifically, when host 52 is invited to participate, or not include the switch that first detected the RSVP Path 
requests participation, in a reserved connection with an message, although this will be unlikely if most or all of the 
upstream/downstream host via public Internet 24 or private switches in the network are upgraded in accordance with the 
network/virtual private network 26 based on the conven- 20 invention. It should be further noted that, preferably, the 
tional RSVP reservation protocol, Path and Resv messages paths in the path list are ordered by number of hops, the first 
will flow within the network between host 52 and router 54. path having the fewest hops. Accordingly, connection con- 
Such messages will necessarily also have to flow through trailer function 64 can farther include functionality for 
one or more intermediate switches 56, although the appli- determining and controlling the maximum latency of the 
cation layer portion of the messages are typically transparent 25 available paths. 

to such switches. In accordance with the invention, however, if aQ available path can provide the requested service for 

switches 56 are upgraded to detect RSVP messages and to the connection, connection controller function 64 sends a 

notify ECP 50 in addition to forwarding them between host bandwidth reservation to each switch 56 in the path via 

52 and router 54. ^ signaling interface function 66 and signaling channel 58. 

More particularly, for example, when a host in another The reservation includes the source and destination of the 

network desires a reserved connection with host 52, a Path connection (e.g., the source and destination MAC addresses 

message will be routed to router 54 via Internet 24 or private of host 52 and router 54 if switch 56 is a Layer 2 switch, and 

network 26, and router 54 will then insert itself as the final perhaps further the source and destination IP addresses of 

hop of the inter-network path of the requested connection 35 host 52 and router 54 if switch 56 is a Layer 3 switch), and 

and perform the usual RSVP path state processing. Router the desired bandwidth in packets per second, for example. 

54 will realize from its routing tables that host 52 belongs to Connection controller function 64 then waits for an 

the network by which it is connected via intermediate switch acknowledgment from each switch 56 to which a reservation 

56 and will forward the Path message to switch 56 accord- request was sent. When all such acknowledgments are 

ingly. The header of the forwarded Path message will received via signaling interface function 66, connection 

include the layer 2 addresses of host 52 as the destination controller function 64 updates the list of existing connec- 

and router 54 as the source. Switch engine 70 of switch 56 tions in connections list 63. Connection controller function 

is enhanced to detect such Path messages (e.g. by checking 64 also alerts connection monitor function 62 that a reserved 

the protocol type in the packet header). When a Path connection has been established, which creates a record 

message is detected, switch engine 70 temporarily buffers 45 regarding the connection to be stored in permanent connec- 

the message and sends a copy to ECP 50 via reserved tion records list 65. 

signaling channel 58. If connection controller function 64 determines from its 

Likewise, when host 52 desires a reserved connection above described processing that there exists no path between 

with a host in another network, it will send a Path message host 52 and router 54 that can fulfill the requested 

to its default gateway, in this case router 54. The header of 50 connection, no special processing will be performed by 

the Path message will thus include the layer 2 addresses of switches 56, and so packets belonging to the connection will 

host 52 as the source and router 54 as the destination. Switch be forwarded with best effort only. Alternatively, connection 

engine 70 of switch 56 is enhanced to detect such Path controller function 64 can go through the list of available 

messages. When it does, it temporarily buffers the detected paths and find the one having the next highest available 

Path message and sends a copy to ECP 50 via reserved 55 capacity. In either event, connection controller function 64 

signaling channel 58. will cause either switch 56 or the downstream one of host 52 

When ECP 50 receives a copy of the intercepted RSVP and rouler 54 to **** a PathErr message back upstream. 
Path message (either from host 52 or router 54), connection After ECP 50 completes its processing to set up the 
controller function 64 looks up the list of available paths connection, it sends a message to the switch 56 that inter- 
between host 52 and router 54 in path list 59. It then 60 cc P ted ^ Path message, causing the switch to forward the 
determines the overall capacity of the first available path by buffered Path message along to host 52 (via one or more 
determining from network elements registry 57 whether the additional intermediate switches 56 if necessary), 
minimum bandwidth available through each link, switch, In this example of the invention, no special processing 
and switch port in the path will be sufficient to fulfill the need be performed by switches 56 or ECP 50 for Resv 
bandwidth and/or quality of service requested for the con- 65 messages corresponding to the intercepted Path message, 
nection. Connection controller function 64 reduces the band- Switches 56 also intercept ResvTear and PathTear mes- 
width available through each link, switch, and switch port in sages and send copies to ECP 50 for processing in addition 
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lo forwarding them on to their upstream or downstream 
destinations. When such a message is received via signaling 
interface 58, connection controller 64 finds the connection in 
its current connection list, deletes the connection and 
updates the list, notifies connection monitor function 62 that 
the connection is ending, and sends bandwidth release 
messages to each switch 56 involved in the connection. 

Focusing more particularly on the operation of switches 
56 illustrated in FIG. 6 according to the invention, as 
described above, reservation interface function 68 of each 
switch 56 receives bandwidth reservation requests from ECP 
50 via reserved signaling channel 58. Such requests include, 
for example, the MAC addresses of host 52 and router 54, 
as well as the desired bandwidth, in bytes or packets per 
second for example. Upon receipt of such a request, reser- 
vation interface function 68 stores the addresses and desired 
bandwidth in connection pairs list 67 and sends an acknowl- 
edgment to ECP 50. Reservation interface function 68 also 
receives bandwidth reservation release requests from ECP 
50 containing, for example, the MAC addresses of the hosts 
and routers involved in the virtual circuit connection that is 
to be released. Upon receipt of such a request, reservation 
interface function 68 deletes the information in connection 
pairs fist 67 corresponding to the released connection and 
sends an acknowledgment to ECP 50. 

Enhanced switch engine 70, in addition to detecting and 
processing sessions using existing and emerging reservation 
protocols such as RSVP as described above, performs con- 
ventional functions of forwarding packets between ports of 
the switch in accordance with addresses in the packet 
headers and the contents of its standard switch table 69. In 
accordance with the principles of the invention, however, 
enhanced switch engine 70 further compares the addresses 
in the packet headers with the addresses contained in con- 
nection pairs list 67. Specifically, if the source and destina- 
tion addresses of an incoming packet match both addresses 
of one of the address pairs stored in its connection pairs list, 
the packet is forwarded to the port associated with the 
destination address, which port is designated by its conven- 
tional switch table 69. Meanwhile, if the port designated by 
switch table 69 for one address of an incoming packet 
matches a port designated by the switch table for any of the 
stored addresses of hosts and routers involved in a reserved 
virtual circuit connection, but if both addresses of the 
incoming packet do not match the corresponding address 
pair stored in its connection pairs list, the packet is dropped 
(if there exist current active connections in connection pairs 
list 67 and sufficient port bandwidth is unavailable). 

It is important to note that this approach does not com- 
promise the fundamental ability of switch 56 (be it a level 2 
switch or level 3 router or switch) to share traffic loads with 
various classes of traffic. It only gives QOS/COS traffic 
preferred access to the available bandwidth of a switch or 
router port. If bandwidth on a port has been reserved by the 
ECP but priority packets are not arriving to make use of that 
bandwidth, "best effort" packets can and will be allowed to 
be forwarded through that port. 

As an alternative, if the switch 56 maintains separate port 
queues for priority traffic, enhanced switch engine 70 can 
forward reserved connection packets to high priority queues, 
while dropping or forwarding to lower priority queues those 
packets which contend for access to ports involved in 
reserved connections. However, it should be apparent that 
the invention is operative whether or not such switches 
maintain more than one port queue per switch port, and 
whether or not such switches support IEEE 802.1P/Q. 

It should be noted as in co -pending application Ser. No. 
09/060,520, that not every switch in the network need be 



upgraded. However, the reserved connection features of the 
invention will be limited to those segments of the path 
between host 52 and router 54 that are under the control of, 
and in communication with, ECP 50. Another example of 

5 network 20 is shown in FIG. 7 to illustrate this alternative. 
In this example, switch 80 is a layer 2 switch or bridge that 
has not been upgraded in accordance with the invention. 
Nevertheless, the invention is operative to secure or deny 
reserved connection services through switches 56, although 

1Q any such reserved connections that are admitted through the 
network will be prone to possible congestion through switch 
80. The switches that have been upgraded in accordance 
with the invention are thus operative to perform reserved 
connection features as long as they lie in packet communi- 
cation with requesting and/or destination hosts or routers, 

15 regardless of how many conventional resources lie between 
the upgraded switches and such hosts and/or routers. 

For traffic within the network, the present invention 
facilitates interoperation with IEEE 802.1 P/Q protocols in 
much the same manner as with RSVP. Although the IEEE 

20 802.1P/Q protocol does not provide for end-to-end signaling 
of reservation requests per se, by signaling a desired priority 
level within the packet, an implicit reservation for a con- 
nection with a desired level or class of service (COS) is 
being made. Another example of a local network 20 having 

25 the additional functionality of the invention that provides 
interoperation with this "reservation protocol" is illustrated 
in FIG. 8. 

Differently from the above-described embodiments, 
however, hosts 92 and 94 within the same network 20 are not 

30 necessarily capable of supporting RSVP, but rather are any 
hosts that support the IEEE 802.1P/Q protocols in a manner 
that is conventionally known. Moreover, although hosts 92 
and 94 are shown having application layer functionality, this 
is not necessarily so. Further, as an alternative, one of hosts 

35 92 or 94 may actually be a router that forwards packets from 
a IEEE 802.1 P/Q compliant host in another network via 
public Internet 24 and/or private network/virtual private 
network 26 (as indicated by the dashed arrow adjacent to 
host/router 94). 

40 Intermediate switches 56 detect packets using the 
extended frame header format of IEEE 802.1 P/Q and com- 
pare the header information within such packets to infor- 
mation regarding current reserved connections in the 
switch's connection pairs list 67. The header information 

45 will include the source and destination address of the packet 
and the desired class of service or priority level If the source 
and destination within the detected packet header informa- 
tion matches that for a current reserved connection stored in 
the list, the IEEE 802.1P/Q packet is forwarded in accor- 

50 dance with the priority assigned for that connection. If the 
header information does not match, the header information 
is forwarded to ECP 50 via the reserved signaling channel, 
and the IEEE 802.1 P/Q packet is dropped (if there exist 
current reserved connections stored in list 67 and sufficient 

55 port bandwidth is unavailable). 

ECP 50 then determines whether a path exists that can 

provide the requested service (either signaled by the "user 

priority" field or by a selected queue) between the source 
and destination hosts, as described in the forwarded header 

60 information. In the process, ECP 50 first maps the requested 
service level to a bandwidth or latency requirement, for 
example by using a stored table. If a path exists, ECP 50 
establishes the connection by sending bandwidth reservation 
requests to each switch 56 in the path. If not, packets 

65 belonging to the requested connection are dropped or are 
assigned a priority that corresponds to the maximum avail- 
able bandwidth. 
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Each time a packet belonging to a reserved connection is 
forwarded by switch 56, it resets a flag associated with that 
connection in connection pairs list 67. Accordingly, switch 
56 can also include functionality similar to LRU processing 
to periodically review the list of reserved connections for 
inactive sessions. For inactive sessions, a message can be 
sent to ECP 50 identifying the reserved connection so that 
ECP 50 can send bandwidth release messages to all switches 
in the path for that reservation. 

There are many advantages that this embodiment of the 
invention provides over conventional networks supporting 
IEEE 802.1P/Q. For example, the desired reservation can be 
maintained consistently throughout the duration of the 
connection, and for each switch from host to host along the 
path. In contrast, in conventional networks, reserved con- 
nections must still contend for access to ports with other 
connections having the same or higher priority, even if such 
contending connections were established after the reserved 
connection. Moreover, switches 56 need not support mul- 
tiple queues per switch port, as is required to effectuate QOS 
in conventional networks. 

A further example of a local area network 20 in accor- 
dance with the present invention is illustrated in FIG. 9. In 
this embodiment, differently from the above-described 
embodiments, the network includes one or more hosts 102 
that have been configured with enhanced functionality for 
directly requesting a reserved connection from ECP 50 
similarly as described in the co-pending application Ser. No. 
09/060,520. 

That is, in this embodiment, host 102 includes a daemon 
process 106 that processes user requests.for reserved con- 
nections with other hosts within the network or in other 
networks. In accordance with requested connections pro- 
cessed by daemon process 106, signaling interface 104 
sends connect/disconnect messages to ECP 50 via reserved 
signaling channel 58. Although FIG. 9 illustrates an example 
where host 102 is communicating with a conventional 
host/router 94, it should be apparent that host 102 can also 
communicate with other hosts similarly upgraded as host 
102. 

FIG. 10 further illustrates one example of the functional 
capabilities of a host 102 adapted for establishing reserved 
connections according to the present invention. As shown, it 
includes a web browser 112, a browser plug-in application 
110, a daemon process 106, a user interface process 108, and 
a signaling interface process 104. The above processes are 
operable within a common operating system such as Win- 
dows 95 or NT from Microsoft Corp. of Redmond, Wash., 
for example. 

Although examples of the above components are fully 
described in detail in the co-pending application Ser. No. 
09/060,520, they will be briefly described here as they are 
adapted for use in the present invention. Web browser 112 is 
preferably a Java-capable browser such as NetScape Com- 
municator 4.0 from NetScape Communications Corp. of 
Mountain View, Calif., for example. Daemon process 106 
provides the functionality needed to take advantage of the 
virtual circuit services according to the present invention, 
and is preferably instantiated on host 102 when it is powered 
on. User interface process 108 responds to user inputs from 
I/O devices attached to host 102 (e.g. keyboard and mouse), 
and draws objects on a video display associated with the 
host. To enable browser 112 to handle URLs unique to the 
reserved connection services of the present invention, 
browser 112 is configured with plug-in application 110, 
whose main function is to notify daemon process 106 when 
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a reserved connection is being requested from the browser. 
Signaling interface process 104 receives requests for par- 
ticipation in, or termination of, a reserved connection from 
ECP 50 via signaling channel 58 and the host's NIC and 
forwards them to daemon process 106 upon receipt, and also 
sends requests for origination or termination of reserved 
connections to ECP. 50 upon command from daemon pro- 
cess 106. 

When host 102 is powered on, daemon process 106 is 
instantiated and starts up signaling interface process 104. 
Daemon process 106 then waits for messages from either the 
browser 112 (via browser plug-in application 110), request- 
ing that a reserved connection be initiated or terminated, or 
from signaling interface process 104, indicating that another 
host is requesting that host 102 participate in, or wishes to 
terminate a reserved connection. 

For example, when a user is running browser 112 and 
desires to originate a reserved connection, a web page that 
contains a directory of users is accessed and the directory is 
displayed in the browser window. The directory contains a 
list of users, whose names are preferably shown as hypertext 
with links having URLs that are unique to the reserved 
connection services of the present invention. When the user 
selects a party or parties from the list, browser 112 invokes 
plug-in application 110 to handle the request, and plug-in 
application 110 in turn notifies daemon process 106. Dae- 
mon process 106 invokes user interface process 108, which 
draws a dialog box on the host's display asking the user to 
specify what kind of connection is desired (e.g., audio only, 
data only, teleconference, etc.). This information is returned 
to daemon process 106 and formatted into a connection 
request that is forwarded to signaling interface 104, which 
sends the request to ECP 50. 

ECP 50 then processes the request similarly as described 
above by checking the resources along the path(s) to the 
requested destination and attempting to secure the desired 
service. If the connection can not be established (e.g., not 
enough bandwidth available, or the other participant does 
not agree to the connection), ECP 50 notifies host 102 to that 
effect via signaling channel 58, which message is received 
by signaling interface process 104. Signaling interface pro- 
cess 104 forwards the message to daemon process 106, 
which in turn commands user interface process 108 to paint 
a message on the host's display informing the user that the 
requested connection was refused. Alternatively, ECP 50 can 
determine the path with the next highest available service 
and advise host 102, which message would be forwarded to 
daemon process 106 via signaling interface process 104. 
Daemon process 106 could then command user interface 
process 108 to paint a message with the advisement and an 
action box for allowing the user to accept or decline the next 
highest available service. 

If the connection can be established with the requested 
service, ECP 50 notifies host 102 to that effect via signaling 
channel 58, which message is received by signaling inter- 
face process 104. Signaling interface process 104 forwards 
the message to daemon process 106, which in turn com- 
mands user interface process 108 to paint a message on the 
host's display informing the user that the requested connec- 
tion was granted. Additional functionality can also be built 
in to launch a software application desired for that connec- 
tion (such as a video or audio conference). 

The message from ECP 50 notifying host 102 that the 
connection can be established also includes the u user_ 
priority" or selected queue that host 102 should use in the 
IEEE 802.1 P/Q frame header of all packets corresponding to 
that connection. 
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At the lime the connection is established, user interface 
process 108 can also paint an action box on the display that 
permits the user to terminate the connection when desired. 
When such an action is desired by the user, the answer is 
collected by user interface process 108 via user I/O devices 5 
and relayed to daemon process 106. Daemon process 106 
then formats a disconnection request message which is sent 
to ECP 50 via signaling interface process 104 and signaling 
channel 58. Upon such a disconnection request from host 
102, ECP 50 sends bandwidth release messages to all 10 
switches 56 involved in the connection. 

Meanwhile, for connection requests sent to host 102 from 
another network host, these are received by daemon process 
106 via signaling interface process 104. These can be 
signaled directly to ECP 50 by another host within the LAN 15 
with similar capabilities as host 102, or they can be requests 
from conventional endstations according to reservation pro- 
tocols such as RSVP or IEEE 802.1P/Q that are intercepted 
along the way and forwarded to ECP 50, which then realizes 
it can signal directly to host 102 whether to accept the 20 
request. When such requests are received by host 102, 
daemon process 106 activates user interface process 108, 
which in turn paints a dialog box on the host's video display, 
querying the user whether to participate in the connection. 
The answer is collected by user interface process 108 via 25 
user I/O devices and relayed to the daemon process 106. 
Daemon process 106 then formats an answer message which 
is sent to ECP 50 via signaling interface process 104. Similar 
processing is performed for connection termination requests 
from other hosts. 30 

Although the process of requesting a reserved connection 
has been described above with reference to the example of 
a user interface process interacting with a user to select a 
type of connection, it should be apparent that many alter- 
natives are possible. For example, additional layers of 35 
software can be built into applications that automatically 
request a connection, determine the type of connection to be 
made, and how much bandwidth and what quality or class of 
service to request for such connection. ^ 

Furthermore, the process of responding to requests for 
connections can be entirely automatic, as could be the case 
in an endstation such as a server. That is, no user interaction 
need be required to respond to requests from network users 
to log onto or access information from the server. 45 
Accordingly, the software load on such endstations could be 
limited to a daemon process such as 106 and a signaling 
interface process such as 104. 

It should be apparent that, similarly to the embodiment 
illustrated in FIG. 7, it is possible in the embodiment 50 
illustrated in FIG. 9 that conventional switches may also lie 
in the path between hosts participating in a reserved con- 
nection. Although the requested COS can not be fully 
guaranteed through such switches in such a configuration, 
the invention is still operable and coexists seamlessly with 5S 
such conventional switches. Furthermore, if the conven- 
tional switch supports IEEE 802.1P/Q, since this example of 
the invention uses such formats, a COS approximate to the 
requested level is possible. 

Further advantages are achieved when the principles of 60 
the invention are extended to inter-network reserved con- 
nections in addition to reserved connections within a local 
network. For example, as illustrated in FIG. 11, LAN A, 
LAN B and LAN C are all connected together via a private 
network/virtual private network 26 such as leased lines, 65 
X.25, Frame Relay, ISDN, or ATM. In this embodiment, 
LANs A and B (20) each have enhanced functionality 



according to the present invention, while LAN C (22) does 
not. Switches 56 in LANs A and B trap RSVP Path and Resv 
messages destined outside their networks (as well as IEEE 
802.1P/Q packets, and packets associated with other reser- 
vation protocols) and inform the respective ECP 51 via the 
respective signaling channel 58. ECP 51 processes the 
information and reserves resources for the connection within 
the local network as described above, and also notifies 
network control system server (NCSS) 30 via signaling 
network 28. Examples of NCSS 30 and signaling network 28 
that can be adapted for use with the present invention are 
fully described in U.S. patent application Ser. No, 08/966, 
634, filed Nov. 10, 1997 and commonly owned by the 
assignee of the present invention, the contents of which are 
fully incorporated herein by reference. For reservation pro- 
tocol messages from and to LAN C, these are not trapped 
until they are detected upstream or downstream in LAN Aor 
LAN B. 

As shown in FIG. 11, network 26 includes one or more 
controllable network elements (NEs) 120 that are connected 
together in a mesh. Some or (preferably) all of the control- 
lable network elements further include a switch commander 
(SC) 122 (as described in co-pending application Ser. No. 
08/966,634) that communicates with NCSS 30 via the 
signaling network 28. The controllable network elements 
120 can be devices such as DACs, ATM switches, ADMs, 
SONET and SONET ATM, IP/ATM or IP/FR concentrators, 
IP switches and routers, QOS routers, Layer 2 switches, 
Optical switches, Frame Relay, Mux/Demuxes and SMDS. 
Accordingly, as will be explained in more detail below, 
when reservation messages are trapped and information 
concerning the flows to which they belong is forwarded to 
NCSS 30, NCSS 30 uses the information to "switch up" the 
connection within network 26 via the certain NEs (if any) 
that are in the path of the flow and that include a switch 
commander. 

FIG. 12 further illustrates an ECP 51 for use in this 
embodiment of the invention. As shown, it further includes 
a network interface function 53 for communicating with 
NCSS 30 via signaling network 28. Such communications 
by network interface function 53 may be according to a 
particular signaling protocol, such as the ITU standard 
signaling protocol Q.931, or other actual and de-facto tele- 
phone and Internet signaling standards, as are known well to 
those versed in the art. Accordingly, when a request for a 
reserved connection is detected within LAN 20, ECP 51 will 
be notified and will secure the necessary resources within 
the network, if available, for the connection, as described 
above. Connection controller 64 makes a further determi- 
nation whether the connection includes the participation of 
a host in another network. If so, ECP 51 signals a connection 
setup request to NCSS 30 via signaling network 28. 

FIG. 13 further illustrates an NCSS 30 according to the 
invention. As shown in FIG. 13, it includes a router 171, a 
director 172, route controllers 173, switch monitors 174, a 
database server 176, and signaling network interfaces 181, 
all connected on a high speed local network 175. The 
database server 176 provides access to disk array 177. Disk 
array 177 is also attached to low speed local network 178 for 
maintenance and billing. Also attached to low speed local 
network 178 are provisioning manager 179, graph calculator 
180, and billing management component. 182. Signaling 
interfaces 181 provide communications to switch command- 
ers 122 associated with network elements 120, which com- 
munications are maintained via signaling network 28 and 
router 171. Signaling interfaces 181 and route controllers 
173 are shown as a plurality of elements to clarify the aspect 
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that there may be more than one instantiation of each active 
at a time. The number of switch monitors 174 corresponds 
to the number of NEs 120 in network 26, and each switch 
monitor 174 is respectively responsible for a corresponding 
NE 120. However, each has the same functionality and 
preferably presents the same interface to other elements of 
the network control system server. 

The above elements are described in detail in co-pending 
application Ser. No. 08/966,634. Briefly, however, as 
adapted for use in the present invention, graph calculator 

180 pre-computes, between every local area network 20, 22 
connected to network 26, all possible paths through all NEs 
120. The resulting list of paths is called a call graph and is 
stored in disk array 177. 

Bandwidth resources available to the network are man- 
aged in terms of facilities (described in more detail in 
co-pending application Ser. No. 08/966,634). Facilities 
information is stored in disk array 177. Provisioning man- 
ager 179 manages this information and cooperates with the 
graph calculator for performing call graph and path calcu- 
lation. This provides the other subsystems in NCSS 30 with 
pre^calculated routing paths and costing information. The 
availability of such pre-calculated and costed paths at con- 
nection time substantially speeds up the processing for 
creating on-demand reserved connections. 

Route controllers 173 of NCSS 30 are instantiated once 
for each reserved connection to be established within net- 
work 26. They perform two major functions: connection 
setup and connection teardown. The process of setting up or 
tearing down a reserved connection within network 26 is 
accomplished with cooperation of the signaling interfaces 

181 and switch monitors 174. Signaling interfaces 181 
communicate with ECPs that have detected requests for 
beginning or ending a reserved connection. Switch monitors 
174 communicate with switch commanders 122 associated 
with NEs 120 to send commands for "switching up" a 
connection along the selected path between the communi- 
cating LANs. Switch monitors 174 also monitor the 
resources instantaneously available within each NE 120 so 
as to provide information regarding whether the NE will be 
able to satisfy the service requested for the reserved con- 
nection. 

The signaling interfaces, route controllers and switch 
monitors also use database server 176 available as part of 
NCSS 30 to store information in disk array 177 about 
reserved connections that are established, billing status, and 
network operations status. Database server 176 and disk 
array 177 can be implemented in many ways known to those 
skilled in the art. 

Billing management component 182 has access to disk 
array 177 via low speed network 178. It collects and formats 
the information recorded therein for output and use accord- 
ing to de-facto standard billing information formats used 
throughout the telecommunications industry. The database 
records relating to network connection events described 
above are queued for reformatting by database server 176 
upon their insertion during the connection teardown pro- 
cessing. 

The operation of the above components for setting up and 
tearing down a reserved connection within network 26 
between two or more LANs 20, 22 will now be described in 
more detail. Particularly, when a reserved connection 
between hosts in LANs 20, 22 is to be made using network 
26, the respective ECP 51 that first detects the "reservation" 
request performs its usual processing for establishing the 
connection within its own network (described previously) 
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and also sends a connection setup request to NCSS 30 over 
signaling network 28. Such setup requests are received by 
signaling interfaces 181. When a signaling interface 181 
receives a request for a reserved connection, a route con- 

5 trailer 173 is activated to set up the connection. The par- 
ticular choice of route controller 173 is made on a load- 
balancing basis by director 172. Associated with the request 
from ECP 51 is the source and destination addresses of the 
requested reserved connection (typically IP addresses), and 
the service requested for the connection. 

Route controller 173 receives the setup message via 
signaling network interface 181 and looks up the addresses 
in disk array 177 via database server 176 and high-speed 
LAN 175. When the source and destination hosts are 
identified, including the respective LANs 20, 22 in which 

15 they exist, the corresponding call graph listing all paths 
through network 26 between the LANs is fetched from disk 
array 177 and returned to route controller 173. The route 
controller then determines a multicast group for broadcast- 
ing messages to switch monitors 174 corresponding to all 

20 underlying NEs in the call graph, and assigns a multicast 
address to the group. This multicast group will last until the 
connection is either connected or released. The route con- 
troller 173 alerts each switch monitor 174 and waits for them 
to all join the group. 

25 After all switch monitors 174 have joined the multicast 
group, for each switch monitor in the multicast group, the 
route controller constructs and sends a "Reserve" message 
stating the list of next-neighbors in the graph, an identifier 
for the requested reserved connection, and the service 

30 requested (e.g. total bandwidth). Alternatively, this message 
can be sent at the same time as the switch monitors are 
alerted and before all switch monitors have joined the group. 

In response to the "Reserve" message, each switch mom- 
tor 174 determines if the requested service is available on 

35 each next-neighbor link. If not already done, each switch 
monitor also simultaneously joins the multicast group for the 
connection. Each switch monitor 174 then multicasts its 
answer (which may be a partial allocation; i.e., if service 
corresponding to 96 bearer channels was requested on 

40 outputs from switch A to switch B, and only 72 channels 
were available, the monitor for NE A would respond with an 
answer such as "A to next -neighbor B: 72 of 95: circuit- 
range circuit-range. . . ") back to route controller 173. 
Route controller 173, having received the multicast 

45 results, identifies and culls out links that can not support the 
requested service and selects the first path (preferably with 
the fewest hops) that can support the requested service as the 
actual path to be used. The route controller also sends a 
"Reserved** message to all switch monitors in the multicast 

50 group, containing the complete connection path. Upon 
receiving this "Reserved" multicast, each switch monitor 
174 then determines what resources are needed on the actual 
connection path for its corresponding NE 120 and releases 
any reserved resources not needed on the path. In addition, 

55 the path selected is written to the disk array 177. Each switch 
monitor with reserved resources then transmits the correct 
connect commands to their respective NE so as to physically 
switch up the connection; as each of these messages is 
queued, the switch monitor sends a "Connect Sent" message 

60 to the multicast group. When all NEs have been sent their 
connect messages, the route controller sends "Connected" to 
each of the participating switch monitors. The route con- 
troller continues to listen for messages from the multicast 
group until each switch monitor responds with "Connected." 

65 When that happens, the route controller commits the 
transaction, frees the multicast group, and releases any 
processor resources it's been using. 
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Teardown transactions can be initiated much like setup includes a signaling network interface 210 that queues 
transactions. The ECP 51 that first detects when a reserved commands from NCSS 30 and sends responses from corn- 
connection is ending (e.g. by monitoring a timeout interval mand controller 202 via the signaling network 28. 
between packets belonging to the connection or by detecting As noted in the co-pending application, the above com- 
a PathTear or ResvTear message) sends a disconnection 5 ponents can be implemented in many known ways, 
request to a signaling interface 181 via router 171. This However, it is preferable that command controller 202 is a 
signaling interface then allocates a route controller 173 and SPARCstation running Solaris 5.5.1 (trademarks of Sun 
informs the route controller of the teardown request. Tear- Microsystems, Inc.) and that ports 204 are X.25 ports, 
down proceeds in similar fashion to setup. The route con- Preferably, switch commanders are implemented on both 
trailer 173 queries the database server to request information 10 Sparc and x86 platforms, and use TCP/IP in general, and 
from database 177 to determine the current state of the entire Telnet specifically, to communicate with NEs 120. It should 
connection. From this information, and from the information be noted, however, that switch commanders 122 may actu- 
saved from the original setup message, the route controller a u y be physically located at the site of NCSS 30. In such a 
determines which two-party reservations need to be released case> x.25 is carried over leased lines (i.e. port lines 206 are 
(that is, for example, for a conference between users A, B, is leased lines) to the appropriate NEs to be controlled, while 
and C, if A wishes to be released, the two-party reservation th e sw itch commander itself is accessed via the network 
between A and B and the two-party reservation between A control system server's own Ethernet, 
and C would need to be released, while the B to C connec- [n tion> thcrcfore> whcn a corresponding switch 
Uon b maintained). It also finds the multicast address that mQ ^ 0T m seQds a « Connecr com[n and to one of NEs 120 
was assigned during setup of those reservations; these 20 attached to 2Q4 ^ m ^ be received b 
multicast tdenufiers are re-used for the teardown phase. s( u netwofk intefface 210 and rd ^ tQ command 
Alternatively, different multicast identifiers could be used. conlroller 20 6. Hie command specifies the specific NE to be 

Route controller 173 then sends unicast messages to each controlled, the amount of resources to be reserved, and the 

of the switch monitors 174 having underlying NEs 120 that crosspoints of the NE between which the connection is to be 

are involved in each of the identified two-party reservations. 25 ma d e . Command controller 206 will translate the command 

Alternatively, route controller 173 broadcasts or multicasts me native language of the NE and transmit the native 

this request. Each involved switch monitor 174 then joins connection command to the corresponding one of ports 204 

the multicast group associated with the two-party teardown v i a ii nes 206. The native connection command will typically 

transaction. When all involved switch monitors have joined, cause me t0 resC rve a specified bandwidth between the 

the route controller issues the information necessary to tear 30 two identified crosspoints of the controllable network ele- 

down the reservation. ment mat will not be released until a subsequent "Release" 

Each switch monitor 174 then communicates, via signal- command is issued, 
ing network 28 and router 171, with the switch commander a further aspect of the invention is illustrated in FIG. 15. 
122 or other switch or router interface associated with the ^ shown in FIG. 15, included within the private network/ 
underlying NEs, to release the reserved connection. When virtual private network 26 are a chain of incompatible NEs. 
the underlying NE acknowledges the release, the switch That is, as shown, messages between LAN A and LAN B 
monitor multicasts the acknowledgement of released must pass through a chain of NEs comprising a first NE 130 
resources. When all switch monitors have acknowledged supporting diff-serv tagging, followed by a NE 132 support- 
release, the route controller 173 issues a "release commit" MPLS, followed by another NE 130 supporting diff-serv 
message on the multicast group. Each switch monitor then tagging. Because MPLS and diff-serv use different tagging 
releases its internal representation of the reservation and schemes, reserved connections attempted between LANs A 
leaves the multicast group. Simultaneously, the route con- an d b would not succeed unless such NEs are capable of 
trailer writes reservation release records to the database sending and receiving packets having both types of tagging, 
server 176 for storage in disk array 177. ^ In ^ embodiment of lhe invention , howe ver, NEs 130 

The route controller then informs the signaling interface an d 132 have been adapted with switch commanders 122 to 

181 of the completion of the transaction. The signaling communicate with NCSS 30 via signaling network 28, and 

interface then releases the route controller 173 for use by are a bi e to t raD slate between formats as directed by NCSS 

other signaling transactions. 30. Accordingly, when reservation protocol messages are 

FIG. 14 further illustrates a switch commander 122 50 trapped in LANs A and B, and NCSS 30 is notified, because 

according to the present invention. The switch commander NCSS 30 knows that different tagging is used in NEs 130 

serves as the interface between NCSS 30 and controllable and 132, it will alert the NEs accordingly when switching up 

network elements such as NE 120. Primarily, switch com- the connection, and cause the NEs to make the appropriate 

mander 122 works to queue and translate commands sent by translation while forwarding the packets belonging to that 

switch monitors 174 in NCSS 30 via signaling network 28 55 connection. 

(preferably TL1 X.25 commands, but often commands that FIG. 16. illustrates an embodiment where LANs A and B 

are proprietary to a particular network element) and the (20) are connected via a broadband network 32 such as that 

particular command language of the underlying network described in co-pending application Ser. No. 08/966,634. In 

element. this embodiment, LANs A and B (20) each have an ECP 51 

Various examples of switch commander 122 are described 60 that communicates with NCSS 30 via signaling network 28. 

in detail in co-pending application Ser. No. 08/966,634. Switches 56 in LANs A and B trap RSVP Path and Resv 

Briefly, however, as adapted for use in the present invention, messages destined outside their networks (as well as IEEE 

switch commander 122 includes a command controller 202 8Q2.1P/Q packets, and other reservation protocols) and 

that translates commands from NCSS 30 into the native forward copies to the respective ECP 51 via the respective 

language of the NEs and communicates the commands to a 65 signaling channel 58. ECP 51 processes the information as 

plurality of NEs 120 attached to ports 204 via port lines 206. described above, and also sends a copy to NCSS 30 via 

In this illustrated example, switch commander 122 also signaling network 28. Examples of NCSS 30 and signaling 
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network 28 that can be adapted for use in this embodiment Network interface card 135 is a standard PCI Ethernet 

of the invention are fully described in co-pending applica- card for transmitting and receiving LAN data packets 

tion Ser. No. 08/966,634. to/from LAN endstations such as host 52 via packet switch 

As further shown in FIG. 16, LANs A and B also each 

include a premises switch 110 (described in co-pending 5 Routing function 133 is shown separately for clarity, but 

application Ser. No. 08/966,634) that communicates with m ^ be "Memented as software running on CPU 136 or 

NCSS 30 via signaling network 28 and also provides an other Pressor. It is responsible for screening data packets 

interface to the infrastructure of the broadband network 32. rcccived ™ P ad f ^ f h * g £ 
» j. * i . * • appropriate output port of bonder 134. It can also perform 
Accordingly, when reservation messages are trapped and ^ ^ ^ additioDal safegua^gainst 
information conceonng the flows to which they belong 1S 10 unauthorized ^ of the 5roadband network by, for example, 
forwarded to NCSS 30 NCSS 30 can determine whether the ^rther screening the destination and source addresses of the 
messages are destined for another network configured to pac kcts and comparing them to a list of authorized users, 
interface with the broadband network, and if so, whether a Bondcr 134 feceivcs broadband nctwork connection data 
path between the hosts involved in the session that can &om workstations such as host 52 via packet switch 
satisfy the requested service exists within the network. If the *5 U2 ^ ^ansmits lhe data to broadband network 32. 
requested connection can be fulfilled by the broadband Conversely, broadband network traffic data received from 
network, NCSS 30 uses the information in the messages to broadband network 32 is relayed by bonder 134 to LAN 
"switch up" the connection via a selected path through the endstations such as host 52 via packet switch 142. 
broadband network, and causes the traffic corresponding to Network address translation function 139 is shown sepa- 
that flow to be forwarded through premises switch 110 in 20 fately for ^ may bc implemcnted ^ 
each LAN 20, rather than through router 54. If the messages ninning on CPU 136 or other processor. It is responsible for 
are not destined for another network having a premises performing address translation of data packets received from 
switch 110, they are forwarded through router 54 as are other endstations such as host 52 via packet switch 142 for 
inter-network messages. forwarding on the broadband network to endstations in other 
Also shown in FIG. 16 is a LAN C (22) not having an ECP 25 networks outside the LAN's address space and for perform- 
51 according to the invention. However, in this example, ing address translation of data packets received over the 
LAN C communicates with an Internet service provider broadband network from other networks outside the LAN's 
(ISP) 34 that is equipped to communicate with broadband address space via bonder 134 and destined for LAN end- 
network 32 and signaling network 28 via a switch com- stations. 

mander 122. Accordingly, NCSS 30 can determine whether 30 Network command translation function 141 is shown 
requests for reserved connections from LANs A and B separately for clarity, but may be implemented as software 
involve LAN C and allow them to be routed through the running on CPU 136 or other processor. It is responsible for 
broadband network 32 rather than through the public Inter- translating and handling network connection commands 
net. In this example, ISP 34 typically includes a QOS router received from switch monitors 174 over the signaling net- 
coupled between broadband network 32 and LAN C (22). wor ie 28 via bonder 134 in a similar manner as described in 

FIG. 17 further illustrates a premises switch 110 adapted connection with switch commander 122. 

for use in the invention shown in FIG. 16. As shown, Bonding function 143 is shown separately for clarity, but 

premises switch 110 includes a routing function 133, bonder may be implemented as software running on CPU 136 or 

134, network interface card 135, CPU 136, RAM 137, ^ other processor. It maintains a list of ports (not shown) that 

network address translation (NAT) function 139, network are used for different broadband network connections, 

command translation (NCT) function 141, and bonding including signaling network traffic, circuit-switched traffic, 

function 143 that all communicate via bus 138. Packet and Internet access. A port can consist of one or more bearer 

switch 142 communicates with network interface card 135 channels. For example, a 6 Mbps circuit-switched connec- 

via an Ethernet link. 45 tion can consist of 96 bearer channels, not necessarily 

Various examples of the above components of premises multiplexed on the same Ti lines. The port for this connec- 

switch 110 are fully described in co-pending application Ser. tion is configured as a list of these channels, over which 

No. 08/966,634. Briefly, however, as adapted for use in the bonder 134 relays broadband data destined for and arriving 

present invention, packet switch 142 receives LAN packet from the broadband network. This list can be updated in 

traffic from intermediate switch 56. By reading their desti- 50 accordance with channel reassignments ordered by NCSS 

nation Ethernet addresses, packet switch 142 passes packets 30. 

not associated with broadband network connections (i.e. As noted in the co-pending application, the installation of 

packets that are not addressed to premises switch 110) premises switch 110 in the existing Local area network 20 is 

through to the existing LAN router 54, while packets asso- totally transparent to the LAN router 54 and other worksta- 

ciated with broadband network connections are routed via 55 tions operating on the LAN 20. Moreover, the process of 

routing function 133 to bonder 134 (i.e. packets that are installing premises switch 110 merely requires splicing into 

addressed to premises switch U0) for transmission via LAN connections to LAN router 54. 

broadband network 32. Likewise, LAN traffic from existing In operation, when a request for a reserved connection is 

LAN router 54 is dispatched via packet switch 142 to LAN detected within LAN 20, ECP 51 will be notified and will 

endstations such as host 52 via switches 56. 60 secure the necessary resources within the network, if 

CPU 136 controls the operations of routing function 133, available, for the connection, as described above. Connec- 

bonder 134, network interface card 135 and RAM 137. It tion controller 64 makes a further determination whether the 

coordinates the conversion of circuit-switched traffic data on connection includes the participation of a host in another 

broadband network connections, possibly spread between network. If so, ECP 51 signals a connection setup request to 

many bearer channels, into LAN type packet-switched data 6S NCSS 30 via signaling network 28. 

packets for further transmission within LAN 20, and vice- When NCSS 30 determines that broadband network 32 

versa. can be used for the requested reserved connection, NCSS 30 
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sends a message to premises switch 110 via signaling 
network 30 to switch up the connection. This message 
includes the channel assignments to be maintained by bond- 
ing function 143 for the connection, as well as an identifier 
for the connection corresponding to the source and destina- 5 
tion addresses of the session (typically IP addresses). CPU 
138 will then send an ICMP re-direct that will cause the host 
52 to send all packets associated with the reserved. connec- 
tion to premises switch 110 instead of router 54. That is, 
more particularly, the ICMP re -direct tells host 52 that the 10 
address associated with the other participant in the reserved 
connection is reachable by sending packets to the MAC 
address of premises switch 110 instead of the MAC address 
of router 54. Accordingly, data belonging to the reserved 
connection will be forwarded to and from host 52 via packet 15 
switch 142 and to and from the host in the other network via 
broadband network 32 and bonder module 134. When the 
reserved connection is torn down, CPU 138 will cause 
another ICMP re-direct to be sent to host 52 instructing host 
52 to send all packets destined to addresses associated with 20 
the other host's network back to router 54 and not premises 
switch 110. 

In another possible implementation, instead of performing 
ICMP re-directs, each endstation includes point-to-point 
router functionality which is told through signaling to route 25 
traffic through the premises switch 110 rather than the 
existing default router 54. 

An important distinction between this embodiment and 
the previous embodiments of the invention is that ECP 51 
will wait for NCSS 30 to determine whether the reserved 30 
connection will use the broadband network before causing 
switch 56 to forward the intercepted Path message. In 
particular, if NCSS 30 determines that the broadband net- 
work will be used, it will send a message indicating such to 
ECP 51 via signaling network 28. ECP 51 will then instruct 35 
switch 56 to recapsulate the temporarily buffered Path 
message as a normal message so that it will propagate 
harmlessly through the network. On the other hand, if the 
broadband network will not be used for the reserved 
connection, ECP 51 will cause the temporarily buffered 40 
message to be forwarded along as a Path message through 
the Internet or private network. 

It should be noted that premises switch 110 may be further 
or alternatively coupled to private network/virtual private 45 
network 26 for establishing reserved connections using 
resources of such a network 26 rather than, or in addition to 
broadband network 32. In such a configuration, the SCP/ 
ECP can grow or shrink connections on demand and there- 
fore provide pipe management for the private networks as 5Q 
well as connections to the public network from the same 
device. 

Referring back to FIG. 16, for broadband network con- 
nections involving ISP 34, requests for such connections 
will be detected within LANs 20 having an ECP 51. NCSS 55 
30 will realize that the endpoint for the broadband connec- 
tion is actually ISP 34, rather than the LAN C, and will know 
that LAN C does not include a premises switch 110. 
Accordingly, the quality of connection between the host 52 
within LAN C and the ISP 34 will depend on the bandwidth 60 
available between them. In some implementations, ISP 34 
can further include a premises switch 110 for providing 
enhanced connection services to hosts 52 in LAN C. 

FIG. 18 illustrates an alternative embodiment of a LAN 
20 for use in the example of the invention illustrated in FIG. 65 
16. In this alternative implementation, intermediate switches 
80 do not include enhanced functionality as previously 
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described, but can be conventional switches, preferably that 
support IEEE 802.1P/Q. Requests for reserved connections 
using broadband network 32 and LAN 20 are made or 
accepted by enhanced host 102, having the enhanced func- 
tionality described above in connection with FIG. 9. When 
such reserved connections are requested, NCSS 30 will use 
SNMP messages relayed through premises switch 110 to 
cause resources to be reserved within intermediate switches 
80 corresponding to the connection. Alternatively, NCSS 30 
will cause ECP 51 to inform host 102 of the IEEE 802.1P/Q 
protocols to use for the connection. 

Although the present invention has been described in 
detail with reference to the preferred embodiments thereof, 
those skilled in the art will appreciate that various substitu- 
tions and modifications can be made to the examples 
described herein while remaining within the spirit and scope 
of the invention as defined in the appended claims. 

What is claimed is: 

1. An apparatus for providing reserved connections 
between endstations, in a single network capable of provid- 
ing best-effort and prioritized communications, comprising: 

a switch in packet communication with the endstations 
that is adapted to detect and forward best-effort packets 
and packets that include requests for reserved connec- 
tions according to a predetermined reservation proto- 
col; and 

an enterprise control point adapted to communicate with 
the switch via a signaling channel, wherein the enter- 
prise control point receives requested information con- 
cerning reserved connections from the switch and is 
adapted to identify at least one path in the network and 
to reserve resources along the path that can satisfy the 
reserved connections between the endstations in 
response to the received information. 

2. An apparatus according to claim 1, wherein the network 
comprises one of a local area network and a wide area 
network. 

3. An apparatus according to claim 1, wherein the prede- 
termined reservation protocol is Reservation Protocol 
(RSVP). 

4. An apparatus according to claim 3, wherein the switch 
is adapted to detect RSVP packets having path messages, to 
buffer the path messages, and to transmit copies of the path 
messages to the enterprise control point. 

5. An apparatus according to claim 1, wherein the prede- 
termined reservation protocol is an IEEE802.1P/Q protocol. 

6. An apparatus according to claim 1, wherein the enter- 
prise control point further comprises: a signaling interface 
adapted to communicate with the switch via the signaling 
channel; 

a path/device discovery unit adapted to build and update 
a list of network elements and paths between the 
endstations; and 

a connection controller coupled to the signaling interface 
and the path/device discovery, wherein the connection 
controller is adapted to initiate and terminate reserved 
connections between the endstations in response to the 
received information. 

7. An apparatus according to claim 1, wherein the switch 
further comprises: 

a reservation interface adapted to forward the information 
concerning reserved connections to the enterprise con- 
trol point and to receive resource reservation informa- 
tion from the enterprise control point via the signaling 
channel; and 

an enhanced switch engine coupled to the reservation 
interface, wherein the enhanced switch engine is 
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adapted to extract the information concerning reserved 
connections from the detected packets and to perform 
packet forwarding decisions based on the received 
resource reservation information. 

8. An apparatus according to claim 1, wherein the end- 5 
stations are capable of communicating via the predetermined 
reservation protocol. 

9. An apparatus according to claim 1, wherein the end- 
stations comprise hosts and/or routers. 

10. An apparatus according to claim 9, wherein the hosts JQ 
and/or routers are capable of communicating via the prede- 
termined reservation protocol. 

11. A method for providing reserved connections between 
endstations in a single network capable of providing best- 
effort and prioritized communications, the method compris- 
ing: 15 

detecting best -effort packets and packets that include 
requests for reserved connections according to a pre- 
determined reservation protocol; 

forwarding best-effort packets; 

forwarding detected request information to an enterprise 20 
control point; 

identifying a path within at least a portion of the network 
between the endstations that can establish the requested 
reserved connections; and reserving resources along ^ 
the path so as to establish the requested reserved 
connections. 

12. A method according to claim 11, wherein the network 
comprises one of a local area network and a wide area 
network. 

13. A method according to claim 11, wherein the prede- 
termined reservation protocol is Reservation Protocol 
(RSVP). 

14. A method according to claim 11, wherein the prede- 
termined reservation protocol is an IEEE802.1P/Q protocol. 35 

15. A method according to claim 11, wherein the endsta- 
tions are adapted to communicate via the predetermined 
reservation protocol. 

16. A method according to claim 11, wherein the detecting 
step includes detecting packets having path messages, buff- 
ering the path messages, and 

wherein the forwarding step includes transmitting copies 
of the path messages to the enterprise control point. 

17. A method according to claim 11, wherein the endsta- 
tions comprise hosts and/or routers. 4S 

18. A method according to claim 17, wherein the hosts 
and/or routers are adapted to communicate via the prede- 
termined reservation protocol. 

19. A method according to claim U, further comprising: 
maintaining a list of connections within the network; build- 5Q 
ing and updating lists of network elements and paths 
between the endstations; and initiating and terminating the 
reserved connections within the network based on the list of 
connections and the lists of network elements and paths 
between the endstations. 

20. A method according to claim 11, further comprising 
extracting request information from the detected packets; 
receiving resource reservation information from the enter- 
prise control point; and 

performing packet forwarding decisions based on the eo 
received resource reservation information. 

21. An apparatus for reserving connections between end- 
stations in a single network, capable of providing best-effort 
and prioritized communications comprising: 

means for detecting best-effort packets and packets that 65 
include requests for reserved connections according to 
a predetermined reservation protocol; 
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means for forwarding best-effort packets; 

means for forwarding detected request information to an 

enterprise control point; 
means for identifying a path within at least a portion of the 

network between the endstations that can establish the 

requested reserved connections; 
and means for reserving resources along the path so as to 

establish the requested reserved connections. 

22. An apparatus according to claim 21, wherein the 
endstations are within the same local area network. 

23. An apparatus according to claim 21, wherein the 
endstations are within the same wide area network. 

24. An apparatus according to claim 21, wherein the 
enterprise control point further comprises: 

means for communicating with a switch via a signaling 
channel; 

means for maintaining a List of connections within the 
network; 

means for building and updating lists of network elements 
and paths between the endstations; and means for 
initiating and terminating the reserved connections 
within the network based on the list of connections and 
the lists of network elements and paths between the 
endstations. 

25. An apparatus according to claim 24, wherein the 
switch further comprises: 

means for extracting request information from the 

detected packets; 
means for forwarding the detected request information to 

the enterprise control point and for receiving resource 

reservation information from the enterprise control 

point via the signaling channel; and 
means for performing packet forwarding decisions based 

on the received resource reservation information. 

26. An apparatus according to claim 24, wherein the 
switch further comprises: 

means for detecting RSVP packets having path messages; 
means for buffering the path messages; and 
means for transmitting copies of the path messages to the 
enterprise control point. 

27. An apparatus according to claim 21, wherein the 
endstations are adapted to communicate via the predeter- 
mined reservation protocol. 

28. An apparatus according to claim 21, wherein the 
endstations comprise hosts and/or routers. 

29. An apparatus according to claim 28, wherein the hosts 
and/or routers are adapted to request and reserve a specified 
bandwidth and/or latency using the predetermined reserva- 
tion protocol. 

30. An enterprise control point adapted to reserve con- 
nections between endstations in a network, wherein the 
enterprise control point is adapted to communicate with a 
switch via a first signaling channel, to receive request 
information concerning reserved connections from the 
switch, and to identify at least one path in the network and 
to reserve resources along the path that can establish the 
reserved connections between the endstations in response to 
the received request information, the enterprise control point 
comprising: 

a signaling interface adapted to communicate with the 

switch via the first signaling channel; 
a path/device discovery unit adapted to build and update 

a list of network elements and paths between the 

endstations; and 
a connection controller coupled to the signaling interface 

and the path/device discovery unit, wherein the con- 
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nection controller is adapted to initiate and terminate 
reserved- connections between the endstations in 
response to the received request information based on 
the list of network elements and paths between the 
endstations. 5 

31. An enterprise control point according to claim 30, 
further comprising a network interface adapted to commu- 
nicate with a network control system server via a second 
signaling network, wherein the network interface is adapted 

to request reserved connections in a wide area network 10 
and/or broadband network. 

32. An apparatus for providing reserved connections 
between endstations in a broadband network, comprising: 

a switch in packet communication with a requesting one 
of the endstations that is adapted to detect packets that 15 
include requests for reserved connections according to 
a predetermined reservation protocol; and 

an enterprise control point adapted to communicate with 
the switch via a signaling channel and to communicate 
with a broadband network control system server via a 20 
signaling network, wherein the enterprise control point 
receives request information concerning reserved con- 
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nections from the switch and to forward the request 
information to the broadband network control system 
server; and 

a premises switch in packet communication with the 
requesting endstation and the broadband network, the 
premises switch being adapted to communicate with 
the broadband network control system server via the 
signaling network and to forward packets belonging to 
reserved connections to a broadband network in 
response to reserved connection commands from the 
broadband network control system server. 

33. An apparatus according to claim 32, wherein the 
premises switch comprises: 

a packet switch adapted to perform packet forwarding 
decisions; 

a network interface card adapted to transmit and/or 
receive packets to/from endstations via the packet 
switch; and 

a bonder adapted to receive and/or transmit packets 
to/from the broadband network. 

* * * * * 
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